This invention relates in general to techniques for generating data base queries and, more particularly, to techniques for generating queries in long running business processes. Even more particularly, the teachings of this invention pertain to generating queries when long running business processes are structured hierarchically and operate on versions of base objects of an application. This invention creates queries for version objects from the queries for the base objects.
Many business processes, such as mortgage application processing and insurance policy underwriting, typically comprise other, smaller processes such as entering information about the applicant, calculating monthly payments etc., which may themselves have sub-processes. As such, these processes and sub-processes form a hierarchy. Such processes can run for several days to a month or even longer. As such, the intermediate results of these processes must be persistent.
These and other business processes typically deal with real world entities such as mortgage application processing, insurance policy underwriting, persons, automobiles, etc.
In a computer handling these processes these real world entities are preferably implemented as objects, and the persistent data corresponding to these objects is preferably managed in a relational data base or an object data base.
Most data base systems are xe2x80x9cupdate in placexe2x80x9d, i.e., only the current data values are maintained in the data base. Typically, these data bases implement single level transactions with so-called Atomic, Consistency, Isolated, Durable (ACID) properties. While the small leaf processes of a business process hierarchy may be suitable for implementation as single level transactions, the larger non-leaf business processes cannot normally be implemented as transactions because of lock contention (data locked for read and write). It is typically not feasible to attempt ACID transactions which have any significant duration. In fact, this becomes feasible only when the nature of the application is such that there is very little lock contention.
To satisfy the requirements of long running business processes which consist of a hierarchy of smaller business processes, and whose intermediate results must be persistent, a Long Running Business Process framework that uses object versions can be constructed. In such a framework the client application deals with two types of object: the unit of work (uow) object which represents a nested long running transaction (provided by the Long Running Business Process framework), and base objects such as an insurance policy that the application writer can relate to. A client application will typically xe2x80x9cjoinxe2x80x9d a unit of work to establish a unit of work context, make method invocations on the base objects, and then xe2x80x9ccommitxe2x80x9d or xe2x80x9croll backxe2x80x9d the unit or work. However, for each base object the Long Running Business Process framework maintains a facade object to represent the base object and version objects, each having as a version identification (id) attribute, the id of the unit of work (uowid) in which it was created.
When a client application makes method invocations on a base object under a given unit of work context, the Long Running Business Process framework maps the method invocations onto the version object visible to that unit of work. The version object visible to a particular unit of work is the version object having a version id that is equal to the id of that unit of work, if such a version object exists, else it is the version object with a version id equal to the id of the parent unit of work or, again, if the parent unit of work does not exist not, the grandparent unit of work, etc. New version objects with version id equal to the current unit of work id are created by copying the version object with the parent unit of work id when an object is modified or, if desired, on a first reference to the object. When the unit of work xe2x80x9ccommitsxe2x80x9d, its version is made available to the parent unit of work.
This approach has several advantages. For example, concurrent updates are permitted as long as there is a mechanism in place to resolve most conflicts. Commonly assigned U.S. patent application Ser. No. 09/236,532, filed Jan. 25,1999, xe2x80x9cSystem and Method for Programming and Executing Long Running Transactionsxe2x80x9d, by A. Leff, F. Parr and J. Rayfield, describes an application-independent technique for resolving conflicts. In other cases application-dependent conflict resolution can be programmed. Also, when the results of processes need to be removed because the process failed, or otherwise needs to be rolled back, then their changes can be removed by removing their versions rather than compensating for their modifications.
Since most business processes involve queries there is a need for the Long Running Business Process framework to support them. In one Long Running Business Process framework known to the inventor queries are written in the client applications. In that case the queries are manually translated into queries expressed in terms of version objects. In another Long Running Business Process framework that is known to the inventor the queries are programmed in the server as finder methods which a client application can invoke.
In either case it would highly desirable to hide from the user the complexity of facade and version objects, by having the programmer specify the query in terms of the base objects, and then letting the system deal with the additional complexity. Thus, it can be appreciated that there is a need for a method for performing queries in a Long Running Business Process Framework system that exhibits this and other desirable traits.
It is a first object and advantage of this invention to provide a method for performing queries in a Long Running Business Process Framework system.
It is another object and advantage of this invention to shield the user from the complexity of facade and version objects, by providing a capability to express a query in terms of base objects.
The foregoing and other problems are overcome and the objects of the invention are realized by methods and apparatus in accordance with embodiments of this invention.
This invention teaches a method for performing queries in a Long Running Business Process Framework system. In a preferred embodiment the method takes as an input the base query, that is, the query expressed in terms of one or more base objects.
In general, the method determines the search condition of a query, if necessary, by parsing the query. The query for the version objects is constructed by defining a sub-set of versions that the issuer of the query should see, and applying the search condition to this sub-set of versions to determine the unique identifications (ids) of the objects satisfying the query. These unique ids are then used to select the objects in the result set of the query.
More particularly, the method includes a step of generating directly, or generating code to generate, a modified base search condition from a base search condition, that is, the search condition of the base query. This is accomplished by replacing names representing objects, for which version and facade objects will be made, with a corresponding visible version sub-query. The method further includes a step of generating directly, or generating code to generate, a facade search condition which specifies that a primary key be one of the primary keys of version objects from the visible version sub-query, that satisfy the modified base query. The method further includes a step of generating code to determine a unit of work context, and to request all facades that satisfy the facade search condition.
The step of generating the visible version sub-query for a class of objects may generate a sub-query which for each primary key determines the maximum length of the version id of all version object instances whose version id is that of the unit of work, or an ancestor unit of work, and a sub-query which selects the version object instances whose version id length is the maximum for that primary key.
Alternatively, the step of generating the visible version sub-query for a class of objects may generate a sub-query which selects versions having as a version id the unit of work id, or if none exist with that primary key, the parent unit of work id, or if neither of these exist, the grandparent unit of work id, etc.
The original and/or translated queries may be expressed in the Structured Query Language (SQL) or in the Object Oriented SQL (OOSQL).
The method may include a step of verifying that a base findxxx method, or that a base query, has an acceptable form.
The step of generating the query to request all facades satisfying the facade search condition may generate a query that associates names to sub-queries, and that then uses those names instead of the sub-queries in the body of the facade search condition.